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BROADCAST/MULTICAST SERVICES WITH 
UNIDIRECTIONAL HEADER COMPRESSION 

BACKGROUND 

[0001] FIELD OF THE INVENTION 

5 [0002] The present invention pertains generally to telecommunications, and particularly 
to the compression of headers of packets such as media packets. 

[0003] RELATED ART AND OTHER CONSIDERATIONS 

[0004] Due to the tremendous success of the Internet, it has become a challenging task 
to make use of the Internet Protocol (IP) over all kinds of links. However, because of 
10 the fact that the headers of the IP protocols are rather large, it is not always a simple 
task to make this come true for narrowband links, such as cellular links, for example. 
As an example, consider ordinary speech data transported by the protocols (IP, UDP, 
RTP) used for Voice-over-IP (VoIP), where the header may represent about 70% of the 
packet resulting in a very inefficient usage of the link. 

15 [0005] The term "header compression" (HC) encompasses the art of minimizing the 
necessary bandwidth for information carried in headers on a per-hop basis over point- 
to-point links. Header compression techniques in general have a more than ten-year- 
old history within the Internet community. Several commonly used header 
compression protocols exist, such as the following: (1) Van Jacobson. Compressing 

20 TCP/IP Headers for Low-Speed Serial Links. IETF RFC 1 144, IETF Network Working 
Group, February 1990; (2) Mikael Degermark, Bjorn Nordgren, Stephen Pink. IP 
Header Compression, IETF RFC 2507, IETF Network Working Group, February 1999; 
and (3) Steven Casner, Van Jacobson. Compressing IP/UDP/RTP Headers for Low- 
Speed Serial Links, IETF RFC 2508, IETF Network Working Group, February 1999, all 

25 of which are incorporated by reference herein in their entirety. 
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[0006] Header compression takes advantage of the fact that some fields in the headers 
are not changing within a flow, or change with small and/or predictable values. Header 
compression schemes make use of these characteristics and send static information only 
initially, while changing fields are sent with their absolute values or as differences from 
5 packet to packet. Completely random information has to be sent without any 
compression at all. 

[0007] Header compression is thus an important component to make IP services over 
wireless, such as voice and video services, economically feasible. Header compression 
solutions have been developed by the Robust Header Compression (ROHC) Working 
10 Group of the Internet Engineering Task Force (IETF) to improve the efficiency of such 
services. 

[0008] Robust Header Compression (ROHC), as defined in RFC 3095 (Bormann, C, 
"RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, 
ESP, and uncompressed", RFC 3095, Internet Engineering Task Force, July 2001), is an 

15 extensible framework for which profiles for compression of various protocols may be 
defined. For real-time multimedia services (e.g. voice, video), the application data is 
transported end-to-end within an IP/UDP/RTP stream. Header compression of 
IP/UDP/RTP is defined by the ROHC profile 0x0001 (ROHC RTP) and is applicable 
for Voice-over-IP (VoIP) services among others. The ROHC RTP header compression 

20 scheme has been designed to efficiently compress the IP/UDP/RTP headers over an 
arbitrary link layer. 

[0009] A number of other ROHC profiles have also been defined for compression. 
Among these are (1) IP/UDP/RTP headers (described in: Jonsson, L. and G. Pelletier, 
RObust Header Compression (ROHC): A Link-Layer Assisted ROHC Profile for 

25 IP/UDP/RTP, IETF RFC 3242, April 2002; and Liu, Z and K. Le, Zero-byte Support 
for Bidirectional Reliable Mode (R-mode) in Extended Link-Layer Assisted RObust 
Header Compression (ROHC) Profile, IETF RFC 3408, December 2002); (2) IP only 
headers (described in: Jonsson, L. and G. Pelletier, RObust Header Compression 
(ROHC): A compression profile for IP, IETF RFC 3843, June 2004); (3) IP/TCP 

30 headers (described in: Pelletier, G., Jonsson, L., West, M. and R. Price RObust Header 
Compression (ROHC): TCP/IP Profile (ROHC-TCP), Internet Draft (work in progress), 
<draft-ietf-rohc-tcp-08.txt>, October 2004); and (4) IP/UDP-Lite/RTP headers 
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(described in: Pelletier, G., RObust Header Compression (ROHC): Profiles for UDP- 
Lite, Internet Draft (work in progress), <draft-ietf-rohc-udp-lite-04.txt>, June 2004). 
All RFCs cited herein are incorporated by reference herein in their entireties. 

[00010] Except for negotiation (see also Bormann, C, Robust Header Compression 
5 (ROHC) over PPP, IETF RFC 3241, April 2002), ROHC profiles only requires framing 
and error detection to be provided by the link layer, while all other functionality is 
handled by the ROHC scheme itself. 

[0001 1] The ROHC profiles defined in RFC 3095, RFC 3242, RFC 3408, "IP-ONLY" 
(Jonsson, L. and G. Pelletier, RObust Header Compression (ROHC): A compression 

10 profile for IP, IETF RFC 3843, June 2004) and "ROHC-UDPLite" (Pelletier, G., 

RObust Header Compression (ROHC): Profiles for UDP-Lite, Internet Draft (work in 
progress), <draft-ietf-rohc-udp-lite-04.txt>, June 2004) support three different modes of 
operation. In short, for a specific context, the mode of operation controls the actions 
and the logic to perform as well as the packet types to use during different states of the 

15 header compression operation. Packet types and formats that are allowed may vary 
from one mode to the other. The Unidirectional mode (U-mode) is used at the 
beginning of any ROHC compression before any transition to other modes may occur. 
The Bidirectional Optimistic mode (O-mode) seeks to maximize the compression 
efficiency and sparse usage of the feedback channel. The Bidirectional Reliable mode 

20 (R-mode) seeks to maximize robustness against loss propagation and context damage 
propagation. 

[00012] When in U-mode, packets are sent from compressor to decompressor only. 
The U-mode is thus usable over links where a return path from decompressor to 
compressor is either not desired or not available. Periodical refreshes are used in U- 
25 mode. The U-mode is particularly applicable to broadcast or multicast channels. 

[00013] The O-mode is similar to the U-mode with the difference that a feedback 
channel is used to send error recovery requests and (optionally) acknowledgements of 
significant context updates from the decompressor to compressor. For most ROHC 
profiles, the U-mode and the O-mode are often indistinctly referred to using the term 
30 U/O-mode, due their rather similar characteristics - such as an identical set of packets 
formats for both modes. 
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[00014] The R-mode differs significantly from the two other modes, mainly by making 
a more extensive usage of the feedback channel and a stricter logic for performing 
context updates. The R-mode also uses a few different packet types only understood 
and useful in this mode. 

5 [00015] Each mode of operation has different properties in terms of compression 
efficiency, robustness and processing complexity. Mode transitions may only be 
initiated by the decompressor. ROHC does not specify how and when each mode 
should be used (other than that ROHC compression must always start in U-mode). 
Therefore, the logic for mode transitions is an implementation decision and may be 

10 based on measurements of the link characteristics, link conditions, implementation 
optimizations for a specific mode or may be based on other algorithms. In particular, 
for Broadcast/Multicast type of services, header compression operates in the 
unidirectional mode (U-Mode) only, as normally for such services a feedback channel 
from decompressor to compressor is not available or desired. 

15 [00016] A header compression scheme (such as a ROHC Profile) can be conceptualized 
and/or realized as a state machine. A challenging task is to keep the compressor and 
decompressor states, called contexts, consistent with each other, while keeping the 
header overhead as low as possible. There is one state machine for the compressor, and 
one state machine for the decompressor. The compressor state machine directly 

20 impacts the level of compression efficiency, as it is an important part of the logic 
controlling the choice of compressed packet type to be sent. The purpose of the 
decompressor state machine is mainly to provide the logic for feedback (if applicable) 
and to identify the packet types for which decompression may be attempted. 

[00017] A compression context contains and maintains relevant information about past 
25 packets, and this information is used to compress and decompress subsequent packets. 
As explained in the ROHC documentation, the context of the compressor is the state it 
uses to compress a header. The context of the decompressor is the state it uses to 
decompress a header. Either of these or the two in combination are usually referred to 
as "context", when it is clear which is intended. The context contains relevant 
30 information from previous headers in the packet stream, such as static fields and 

possible reference values for compression and decompression. Moreover, additional 
information describing the packet stream is also part of the context, for example 
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information about how the IP Identifier field changes and the typical inter-packet 
increase in sequence numbers or timestamps. 

[00018] Fig. 1 shows the compressor state machine for the ROHC profiles defined in 
RFC 3095, RFC 3242, RFC 3408, "IP-ONLY" (Jonsson, L. and G. Pelletier, RObust 
5 Header Compression (ROHC): A compression profile for IP, IETF RFC 3843, June 
2004) and "ROHC-UDPLite" (Pelletier, G., RObust Header Compression (ROHC): 
Profiles for UDP-Lite, Internet Draft (work in progress), <draft-ietf-rohc-udp-lite- 
04.txt>, June 2004). For ROHC compression, the three compressor states are the 
Initialization and Refresh (IR), First Order (FO), and Second Order (SO) states. The 

10 compressor starts in the lowest compression state (IR) and transits gradually to higher 
compression states. The compressor will always operate in the highest possible 
compression state, under the constraint that the compressor is sufficiently confident that 
the decompressor has the information necessary to decompress a header compressed 
according to that state. See, e.g., RFC 3095, section 4.3.1 (Carsten Bormann, et al. 

15 RObust Header Compression (ROHC): Framework and four profiles: RTP, UDP, ESP 
and uncompressed; IETF RFC 3095, April 2001). In particular while operating in U- 
Mode, decisions about transitions between the various compression states are normally 
taken by the compressor on the basis of variations in packet headers and periodic 
timeouts. 

20 [00019] According to RFC 3095, section 4.3.1, the purpose of the Initialization and 
Refresh (IR) State is to initialize the static parts and may be the dynamic part of the 
context at the decompressor or to recover after failure. In this state, the compressor 
sends complete header information. This includes all static and nonstatic fields in 
uncompressed form plus some additional information. The compressor stays in the IR 

25 state until it is fairly confident that the decompressor has received the static information 
correctly. 

[00020] The compressor must then have enough confidence that the decompressor has 
the proper context before a transition to a higher compression ratio takes place. This 
confidence may be achieved in U-mode by sending a number of context initialization 
30 packets repeatedly for a large enough interval. The use of a number of packets may 
achieve confidence in less than one round trip time (RTT) but cannot absolutely 
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guarantee that the decompressor does have the proper context other than optimistically 
expect to be successful with a high percentage rate. 

[00021] In describing the Unidirectional mode, RFC 3095 states that "... [Transition 
to a higher compression state in Unidirectional mode is carried out according to the 
5 optimistic approach principle. This means that the compressor transits to a higher 

compression state when it is fairly confident that the decompressor has received enough 
information to correctly decompress packets sent according to the higher compression 
state. When the compressor is in the IR state, it will stay there until it assumes that the 
decompressor has correctly received the static context information. For transition from 
10 the FO to the SO state, the compressor should be confident that the decompressor has 
all parameters needed to decompress according to a fixed pattern." 

[00022] In addition, to ensure robustness, a compressor operating in U-mode 
periodically transits back to a lower compression state (e.g. IR state). In this respect, a 
periodic refresh of the context in U-mode can be viewed as a procedure similar to the 
15 context initialization. 

[00023] The IR state is thus the state were the compression level is the lowest. Fig. 2, 
taken from RFC 3095, section 5.3.1, describes the U-Mode state machine. In the U- 
mode state machine of Fig. 2, Timeout_l typically corresponds to a periodic sending of 
the static (and possibly also dynamic) parameters of the decompressor context, while 
20 Timeout_2 typically corresponds to a periodic sending of only the dynamic parameters 
of the decompressor context. 

[00024] In addition, the context replication (CR) mechanism for ROHC profiles 
introduce an additional state, the CR state. See, Pelletier, G., Robust Header 
Compression (ROHC): Context replication for ROHC profiles, Internet Draft (work in 

25 progress), <draft-ietf-rohc-context-replication-01.txt>, October 2003. To date, only the 
[ROHC-TCP] profile specifies support for context replication, but other profiles may 
also support it provided their corresponding standard is updated. The CR state may 
also be used by a profile operating in U-Mode. Fig. 3 shows the logic added to the 
previous state machine for the CR state. In U-Mode, downward transitions are 

30 performed according to the same logic as described above. 
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[00025] Fig. 4, taken from RFC 3095, section 5.3.2, illustrates an example U-Mode 
decompressor state machine. The state of the decompressor dictates what type of 
compressed packet may be decompressed. In the No Context (NC) state, only packets 
initializing the static part may be decompressed (e.g. ROHC IR packets). In the Static 
5 Context (SC) state, only packets containing sufficient information on the dynamic 

parameters (e.g. ROHC IR-DYN or UOR-2 packets) may be decompressed. In the Full 
Context (FC) state, any packet may be decompressed. Thus, depending on the 
condition of the channel and on the success rate of the decompression, the 
decompressor state machine will transit between the different states and will have to 
10 wait for the reception of a suitable packet for attempting decompression. 

[00026] In unidirectional operation, there is no feedback sent back to the compressor. 
Therefore, in unidirection operation, the decompressor may (in the worst cases) have up 
to Timeout_l of waiting time without possibility to start decompression of the received 
packets, and up to Timeout_2 before it can re-start compression after severe context 
15 damage to the dynamic information. 

[00027] For the ROHC framework, context initialization requires the compressor to 
start using the lowest compression state, the Initialization and Refresh (IR state). The 
first transmitted packets are IR packets to initialize at least the static and the dynamic 
part of the context. The static part may include information such as Context Identifier 
20 (CID), compression profile, the IP source and destination addresses, the UDP source 
and destination ports, SSRC etc. The dynamic part includes information such as RTP 
sequence number (RTP SN), payload type, timestamps, timestamp stride etc. 

[00028] The ROHC framework requires that initialization first uses a number of IR 
packets, and then possibly followed by a number of IR-DYN packets. The size of these 
25 packet types, excluding the payload bits, is in the order of tens of octets. 

[00029] Initialization and periodic refreshes of a header compression context thus 
require bandwidth for the bits necessary to be exchanged between compressor and 
decompressor, and this step is necessary to ensure that higher compression efficiency 
may be achieved. The confidence from the compressor that the decompressor has 
30 achieved proper context implies a certain delay for which the compression efficiency is 
far from optimal. In some situation, for example real-time VoIP flows over very 
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narrow bandwidth wireless links using 0-byte header compression algorithms, such 
delay may impact perceived quality until optimal compression efficiency is reached. 
While the impact for a constant flow is minimal and concealed to the first packets of the 
flow, it may be more significant for a more bursty and discontinuous flow and should 
5 be minimized. 

[00030] When used over error prone unidirectional links such as wireless broadcast 
links, a ROHC compressor operating in unidirectional mode (U-mode) faces a very 
important trade-off between efficiency and reliability. More specifically, when 
improving spectral efficiency of a header compression operating in a unidirectional 
10 mode, both the reliability of the context initialization and the delay to reach the static 
context state (or full context) at the decompressor (that is the delay from the time when 
the mobile station joins the channel and the time the decompressor in the mobile station 
can obtain the static context information) must be considered. 

[00031] When the periodic transition to initialization and refresh (IR) state in the 
15 compressor (Timeout_l) is set to a long interval, fewer large IR packets are transmitted, 
leading to higher bandwidth efficiency. However, since the wireless links have high 
error rate, there is a fairly high probability for the transmitted packets to be corrupted 
and cause repeated decompression failures at the decompressor. Once it is forced back 
to no context (NC) state by such failures, the decompressor may have to wait for a long 
20 time until it receives the periodic IR packets from the compressor necessary to re- 
establish the context. All packets received during this interval have to be discarded, 
causing disruption in the service. In addition, the long IR refresh interval will lead to 
long acquisition time when a MS initially tunes to or switches back to the broadcast 
channel because the decompressor in the MS cannot be updated immediately. 

25 [00032] On the other hand, if the periodic transition to the IR state in the compressor 
(Timeout_l) is set to happen with a short interval, the decompressor will be able to 
recover from context loss promptly, achieving higher reliability, and the tuning time for 
the mobile station will also be short. However, the large number of IR packets sent will 
lead to much lower efficiency. Therefore, there is a trade-off in bandwidth efficiency 

30 when frequently sending IR packets. 
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[00033] The access time is dependent on the time it takes to successfully obtain the 
static part of the context and begin decompression of compressed headers. It is thus 
directly related to the interval between the periodic refreshes as set by the compressor. 

[00034] Broadcast and multicast (BCMCS) services differ from unicast services in that 
5 they do not specifically target a single receiver, but are rather forms of transmission 
where multiple recipients will receive the service. Where unicast transmit to an address 
(either network or link-layer address) corresponding to one and only one receiver, 
broadcast and multicast uses addresses shared by a number, or a group, of receivers. A 
broadcast is generally a transmission that can be received by anyone who can tune to 
10 the channel, while multicast is a transmission between a sender and multiple specific 
receivers on a network. 

[00035] For broadcast/multicast services using ROHC in U-mode, it is desirable to 
insure a short access time to the IP service (including fast context initialization). This 
must be done while minimizing the overhead introduced by the header compression 
15 algorithm, which purpose is to ensure reliability in the absence of a feedback channel 
between the decompressor and the compressor. 

[00036] The document "Broadcast/Multicast Services - Stage 1", Revision A, 3GPP2, 
S.P0030-A Version 0.4.3, June 12, 2003, states in section 7.1 thereof that, for BCMCS 
transmission of data, that it will be possible to use IP Header Compression. Of 
20 particular interest for BCMCS services is the robustness characteristics of the header 
compression scheme over a channel with relatively high bit error rates, with no or 
limited link retransmissions, and with no or limited feedback capability. With respect 
to this, ROHC has a clear advantage when compared to other existing header 
compression schemes such as CRTP and eCRTP. 

25 [00037] Further, section 8.1.6 the 3GPP2, S.P0030-A Version 0.4.3, June 12, 2003, 
document states that a BCMCS service to a user "shall be activated upon request for a 
BCMCS program for which the user is authorized". 

[00038] A framework document, Broadcast/Multicast Services (BCMCS) Framework 
Draft Document, Version 1.2, 3GPP2 BCMCS ad-hoc group, May 2003, provides an 
30 architectural overview and a framework description of the Broadcast-Multicast Service 
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(BCMCS) for the cdma2000 @1 networks. The main purpose of the BCMCS is to allow 
optimization of the use of the cdma2000® radio interface for delivery of BCMCS 
content stream(s) to one or more terminals in one or more regions of an operator's 
network. 



5 [00039] The framework document defines the use of a controller. Section 4.2, page 12, 
of the framework document specifically includes in the architecture an interface 
between this controller and a Packet Data Serving Node (PDSN). The Packet Data 
Serving Node (PDSN) is similar in functionality to 3GPFs SGSN node. This BCMCS 
controller/PDSN interface provides BCMCS session-related information such as Flow 

10 Treatment (e.g., header compression, or header removal), the mapping between the 

identifiers used to distinguish the BCMCS flows (BCMCS_FLOW_ID), and Multicast 
IP address and port number from the BCMCS Controller to the PDSN. This interface 
also exchanges the BCMCS authorization information for bearer path setup of BCMCS. 

[00040] The framework document (in section 4.2, page 13) also includes an interface 
15 between the BCMCS controller and the mobile terminal. The purpose of this BCMCS 
controller/mobile station interface is to provide the BCMCS client application in the 
mobile station (MS) with access to information about available BCMCS sessions: 
including Content Provider Name, Content Name, BCMCS_FLOW_ID(s), start time of 
the BCMCS session, duration of the BCMCS session, flow treatment (e.g., header 
20 compression, or header removal), and session description (e.g., codec type), and the 
transport and application protocols etc, 

[00041] The BCMCS bearer paths are connections between a base station controller 
node (BSC) and a packet control function (PCF) and between the packet control 
function (PCF) and the Packet Data Serving Node (PDSN). The packet control 
25 function (PCF) is an entity in a radio access network that controls the transmission of 
packets between the base station and the PDSN, and is often physically integrated with 
the base station. The BCMCS bearer paths are setup by the network upon registration 
by the user using IOS signaling messages (likely within a block of bits - BLOBs). 
BCMCS services use their own connections, independent of other existing non- 
30 BCMCS service instances to the mobile station. 
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[00042] The framework document also states that upon the bearer path being 
established, if header compression is enabled by the PDSN, the PDSN will periodically 
send the header context on the same bearer path. 

[00043] Jin, Haipeng, and Wang, Jun, "Header Compression For BCMCS", October 
5 2003, propose and advocate the use of ROHC in unidirectional mode as the preferred 
header compression algorithm for BCMCS services. The proposal also includes the 
adoption of modifications to the ROHC unidirectional mode of operation for header 
compression in BCMCS. It is alleged that the existing unidirectional mode of operation 
in ROHC does not work efficiently enough when used over broadcast links with 

10 significant error rates and scarce bandwidth. The proposal suggests that static context 
information be sent in advance to the decompressor via BCMCS information 
acquisition, on a separate channel. This proposal entirely disables the ROHC IR state 
when operating in U-mode in BCMCS services, and sends the IR parameters out-of- 
band instead - only once during channel information acquisition. Should a 

15 decompressor lose its context, the mobile terminal should initiate a new registration to 
the service to trigger a new channel information acquisition exchange. Yet this 
proposal requires significant changes to the state machine logic, as well as an 
unnecessarily complex interaction between the header compression algorithm and the 
underlying system. A simpler approach would be preferable. Also, this proposal is 

20 limited to one IP multicast/broadcast flow per ROHC instance (ROHC channel). This 
can pose unnecessary constraints on the processing and memory usage required in the 
terminal. 

[00044] International Patent Publication WO2004017577 relates to aggregation of 
feedback from mobile terminals within a MBMS serving area, in order (based on a 
25 threshold) to decide to perform downward transitions from SO to FO to IR. This WO 
seeks to improve error recovery of ROHC in U-mode using a tradeoff between a 
number of terminals in need of recovery verses spectral efficiency. The WO targets the 
scaling of multicast and broadcast services where a return channel for ROHC in U- 
mode is employed or where such return channel is provided in a RRC layer. 

30 [00045] Thus, one problem is that, when operating in U-Mode, efficiency is limited 

from the tradeoff between the frequency of context updates (e.g. downward transitions) 
for the purpose of maintaining synchronized contexts at both ends of the link, and the 
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time for a decompressor having no suitable context to resynchronize with the 
compressor context - such as after a burst of errors or when acquiring the 
broadcast/multicast channel. 

[00046] What is needed, therefore, and an object of the present invention, is a 
5 technique reducing access time and improving compression efficiency in 

broadcast/multicast IP services with unidirectional header compression within a 
multicast/broadcast multimedia system. 



BRIEF SUMMARY 

[00047] A communications network, apparatus, and method make a multicast/broadcast 
io multimedia service available to a remote unit over an air interface, and in so doing 
include compression of headers of the media flow. The network and method involves 
generation, external to header compression logic, of a trigger signal which is applied to 
a compressor to trigger a lowest compression state of the header compression logic. 

[00048] In an example embodiment, the communications network comprises a 
15 multicast/broadcast multimedia server which makes the multicast/broadcast multimedia 
service available to the remote unit over the air interface. A header compressor 
subjects the media flow to unidirectional header compression logic for compressing the 
headers of the media flow. A network node, upon receiving a request indicating that 
the remote unit seeks access to the multicast/broadcast multimedia service, generates a 
20 trigger signal which is applied to the compressor to trigger a lowest compression state 
of the header compression logic. The trigger signal is generated external to the header 
compression logic, and prior to generation of an initial packet of the media flow by the 
multimedia server. Preferably the trigger signal is derived using one or more 
broadcast/multicast channel acquisition events initiated by the remote unit. 

25 [00049] Thus, even though the compressor may be configured by convention or 

standard to start the lowest compression state upon receiving an initial packet of the 
media flow, the lowest compression state is instead begun by the external trigger signal. 
The example network and method is thus compatible with robust header compression 
(ROHC) in a unidirectional mode, wherein the compressor has the Initialization and 

30 Refresh (IR) state as its lowest compression state. 
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[00050] The network node can be, for example, the node at which the multimedia 
server resides. The compressor is preferably situated at a packet data serving node 
(PDSN), but may also be situated at a node of the radio access network (RAN). The 
multimedia server can also be situated at the packet data serving node (PDSN). 

5 [00051] As both a distinct and combinable aspect, the network node can generate the 
trigger signal to trigger a transition to the lowest compression state of the header 
compression logic upon receipt of an indication of a decompression problem which has 
occurred at the remote unit. The decompression problem can be, for example, a 
compression initialization failure or compression static context damage. The indication 
10 of the decompression problem is preferably an attempt by the remote unit to reinitiate 
access to the multicast/broadcast multimedia service. 

[00052] Thus, there is also provided a remote unit which receives a multicast/broadcast 
multimedia service from a communications network over an air interface 
communications network, with a media flow of the multicast/broadcast multimedia 

15 service being subject to unidirectional header compression logic for compressing 

headers of the media flow. The remote unit comprises a transceiver for receiving the 
media flow and a decompressor. The decompressor is arranged so that, upon 
encountering a decompression problem with the media flow, the decompressor sends a 
request to reinitiate access to the multicast/broadcast multimedia service to the 

20 communications network (with an expectation that the request to reinitiate access will 
trigger a lowest compression state of the header compression logic). 

[00053] Thus, the external trigger signal is generated either upon a remote unit seeking 
initial access to a multimedia service, and/or upon the remote unit (having suffered a 
decompression problem) seeking to reinitiate access to the multimedia service. The 

25 external trigger signal thus obviates the conventional practice of having the compressor 
periodically (e.g., at the end of predetermined timeouts) returning (often needlessly) to 
the lowest compression state. The external trigger signal thus promotes spectral 
efficiency in the transmission of the broadcast and multicast services by reducing the 
overhead incurred from the periodic sending of larger packets involved in the lowest 

30 compression state, and tends to minimize delay. 
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[00054] BRIEF DESCRIPTION OF THE DRAWINGS 



[00055] The foregoing and other objects, features, and advantages of the invention will 
be apparent from the following more particular description of preferred embodiments as 
illustrated in the accompanying drawings in which reference characters refer to the 
5 same parts throughout the various views. The drawings are not necessarily to scale, 
emphasis instead being placed upon illustrating the principles of the invention. 

[00056] Fig. 1 is a diagrammatic view of an example compressor state machine. 

[00057] Fig. 2 is a diagrammatic view of an example U-Mode state machine. 

[00058] Fig. 3 is a diagrammatic view showing logic added to a state machine for the 
io CR state. 

[00059] Fig. 4 is a diagrammatic view showing an example U-Mode decompressor 
state machine. 

[00060] Fig. 5 is a schematic view of a first example embodiment of a communications 
network wherein an external trigger signal is used to transitioning a packet header 
15 compressor to a lowest compression state. 

[00061] Fig. 6 is a diagrammatic view of an example compressor state machine which 
receives an external trigger signal for transitioning to a lowest compression state. 

[00062] Fig. 7A is a schematic view showing a first example variation of the 
communications network of Fig. 5; Fig. 7B is a schematic view showing a second 
20 example variation of the communications network of Fig. 5 

[00063] Fig. 8 is a timing diagram illustrating basic, representative, example steps or 
events included in an example method of using an external trigger signal for 
transitioning a packet header compressor to a lowest compression state. 



25 



[00064] Fig. 9 is a schematic view of a second example embodiment of a 
communications network wherein an external trigger signal is used to transitioning a 
packet header compressor to a lowest compression state. 
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[00065] Fig. 10 is a diagrammatic view showing basic, representative, example steps 
performed by a header decompressor of a remote unit of the network of Fig. 9. 

[00066] DETAILED DESCRIPTION OF THE DRAWINGS 

[00067] In the following description, for purposes of explanation and not limitation, 
5 specific details are set forth such as particular architectures, interfaces, techniques, etc. 
in order to provide a thorough understanding of the present invention. However, it will 
be apparent to those skilled in the art that the present invention may be practiced in 
other embodiments that depart from these specific details. In other instances, detailed 
descriptions of well-known devices, circuits, and methods are omitted so as not to 
10 obscure the description of the present invention with unnecessary detail. Moreover, 
individual function blocks are shown in some of the figures. Those skilled in the art 
will appreciate that the functions may be implemented using individual hardware 
circuits, using software functioning in conjunction with a suitably programmed digital 
microprocessor or general purpose computer, using an application specific integrated 
15 circuit (ASIC), and/or using one or more digital signal processors (DSPs). 

[00068] Fig. 5 shows an example, non-limiting, representative communications 
network 20 which forms a suitable context for providing a broadcast/multicast 
multimedia service. The communications network 20 includes a multicast/broadcast 
multimedia server 21 which generates packets or otherwise serves as a packet source 
20 for a multicast/broadcast multimedia service. The multicast/broadcast multimedia 

server 21 generates or supplies media packets such as packet 22. Typically each media 
packet has a media payload (MPAY) and header (MH), and (as shown in Fig. 5) is 
applied to a protocol stack 23. 

[00069] The protocol stacks 23 serve to affix protocol headers 24 to the media packet 
25 22. The particular protocols comprising the protocol stack can vary, and typically 
comprise an application protocol (AP), under a transport protocol (TP), under an 
Internet Protocol (IP). In one example implementation, the protocol headers 24 
comprise IP, UDP, and RTP headers which are added to the media packet 22. 
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[00070] The media packet 22 with its appended protocol headers 24 is applied to a 
packet header compressor 25. The packet compressor 25 compresses the protocol 
headers 24, resulted in a compressed header 26 for the packet. 

[00071] The media packet 22 with its appended protocol headers 24 is applied to a 
5 packet header compressor 25. The packet compressor 25 compresses the protocol 

headers 24, resulted in a compressed header 26 for the packet. The header compressor 
25 performs header compression according to any of many suitable header compression 
algorithms, either conventional (such as ROHC, for example) or otherwise. After the 
header of the packet is compressed by header compressor 25, a packet formatter 27 

io incorporates the compressed header into a packet which is applied to a transceiver 29. 
The transceiver 29 serves to transmit the packet, such as packet 30 with its compressed 
header 26, in a flow 34 of packets over link 36 across an interface 38 to a remote unit 
40. The flow 34 of packets, likely most with compressed headers, need not be 
continuous, but can instead be sporadic, depending on the type of packet service 

15 involved and the nature of the material included in the packet service (e.g., media type). 

[00072] The packet stream issuing from packet source 21 of Fig. 5 can be realized in 
various ways. For examples, the packet stream can either (1) be pre-recorded and sent 
by a server (in this case the media in the media packet 22 is already encoded); (2) come 
from a transcoder (which adapts the original media from a source to another media 

20 encoding potentially more suitable and/or supported by terminals); or (3) come from a 
source that performs real-time encoding of live media. Thus, the header compressor 
can receive an input media packet from any of several types of media sources 
somewhere within the IP network. The packet source 21 can be any suitable source, 
such as a media server, for example, and may be located in a node or network common 

25 or remote from header compressor 25. 

[00073] The aforementioned telecommunications elements, illustrated to the left of 
interface 38 in Fig. 5, are illustrated only as certain representative elements germane to 
the present discussion, and understandably do not constitute the whole of the 
telecommunications network 20, as many other unillustrated elements are also present. 
30 Moreover, the set of illustrated elements may be distributed throughout one or more 

nodes or networks (e.g., core networks or radio access networks), and in some instances 
an individual element itself may be distributed to plural platforms and/or plural nodes. 
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Thus, for sake of simplification the illustrated elements are shown as being connected 
directly and successively together in the manner of Fig. 5. 

[00074] While remote unit 40 has numerous elements, certain basic, representative 
elements suitable for an understanding of the header decompression performed by 

5 remote unit 40 are shown in Fig. 5. Among these elements are transceiver 42, which 
applies packets received on link 36 to a packet deformatter 44. The packet deformatter 
44 serves essentially to extract a compressed header from the received packet. After 
the compressed header is extracted, it is sent to header decompressor 46 for 
decompression. After the header of a packet has been decompressed by header 

10 decompressor 46, the packet including its decompressed header is stored by buffer 
manager 48 in decompressed packet buffer 49. The buffer manager 48 also retrieves 
decompressed packets from decompressed packet buffer 49 as needed for the packet 
utilization application 50, e.g., the particular application which is involved in receiving 
a media stream or the like. In addition, remote unit 40 optionally includes a packet 

15 formatter 52 for preparing packets to be sent back across link 36 (as well as various 
unillustrated elements upstream from packet formatter 52). 

[00075] The remote unit 40 may take the form of, or also be known as, any of 
numerous devices/appellations such as mobile station, mobile terminal, wireless 
terminal, or user equipment unit. In the illustrated embodiment of Fig. 5, remote unit 

20 40 happens to be wireless. As such, the remote unit 40 receives radio frequency 

transmissions over an air or radio interface, depicted by dashed-dotted line 38 in Fig. 5. 
Use of a wireless remote unit 40 is consistent with, for example, the RFCs cited herein 
and incorporated by reference. Yet it will be appreciated that the header decompression 
techniques described herein are not limited to use with any particular type of remote 

25 terminal or terminal interface, and that the techniques can instead or additionally be 
utilized for transmissions that are not wireless, or are by types of radiation or waves 
other than radio waves. 

[00076] The header compressor 25 serves to compress headers of packets (such as 
media packets) which have been supplied by packet source 21 and possibly additionally 
30 encoded. The packet header compressor 25 is essentially a state machine which 

operates in various compression states, including a lowest compression state and one or 
more higher order compression states. In conjunction with its lowest compression state, 
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header compressor 25 sends context information to decompressor 46 for use by the 
decompressor in decompressing compressed headers of the media packets. As used 
herein, "context information" encompasses one or both of context initialization 
information and context refresh information. 



5 [00077] Fig. 6 illustrates, from a state machine perspective, an example implementation 
of packet header compressor 25 wherein the packet header compressor 25 employs the 
Unidirectional mode (U-mode) of RObust Header Compression (ROHC). The three 
ROHC states illustrated in Fig. 6 are the lowest compression state, the Initialization and 
Refresh (IR) state; the First Order (FO) state, and Second Order (SO) state. The packet 

io header compressor 25 starts in the lowest compression state (IR) and transits gradually 
(e.g., successively) to the higher compression states. 

[00078] The communications network 20 further includes a network node 60. The 
network node 60 is a node which receives a request message or signal depicted as 
access request 62 in Fig. 5. The access request 62 indicates that the remote unit 40 

15 seeks access to the multicast/broadcast multimedia service provided by 

multicast/broadcast multimedia server 21. In one example implementation the protocol 
for the access request 62 can be a Broadcast Control Protocol and the particular 
message used for accessing the service can be a message know as 
"BCMCSFlowRegistration message for dynamic broadcast", such protocol and 

20 message being described, e.g., at < http://www.3gpp2.org/Public html/specs/C.S0054- 
0 vl.O 02 1704.pdf > http://www.3gpp2.org/Public html/specs/C.S0054- 
0 vl.O 021704.pdf "cdma2000 High Rate Broadcast-Multicast Packet Data Air 
Interface Specification". 

[00079] Upon receiving access request 62, network node 60 generates a trigger signal 
25 64. For this reason, network node 60 is also herein known as the "triggering" node. 
The trigger signal 64 is applied to packet header compressor 25 to trigger a lowest 
compression state of the header compression logic, e.g., the Initialization and Refresh 
(IR) state when using ROHC. The trigger signal 64 is generated external to the header 
compression logic, and thus prior to generation of an initial packet of the media flow by 
30 the multimedia server 21. The trigger signal 64 is internal to an implementation of the 
triggering node 60/PDSN node 70 and the BCMCS controller, which can be the same 
node in most cases. As shown in Fig. 5, the network or triggering node 60 can be, for 
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example, the node at which the multimedia server 21 resides, e.g., the node which hosts 
the multicast/broadcast multimedia server 21. 



[00080] The access request 62 can take the form of one or more broadcast/multicast 
channel acquisition events initiated by remote unit 40. Thus, the access request 62 can 
5 be, for example, the type of activating request contemplated by section 8.1.6 the 
3GPP2, S.P0030-A Version 0.4.3, June 12, 2003. In turn, the trigger signal 64 can 
preferably be derived using the one or more broadcast/multicast channel acquisition 
events initiated by remote unit 40. The trigger signal 64 can be applied, for example, 
over an interface such as the BCMCS controller/PDSN interface described in the 
10 framework document, Broadcast/Multicast Services (BCMCS) Framework Draft 

Document, Version 1.2, 3GPP2 BCMCS ad-hoc group, May 2003, section 4.2, page 12. 

[00081] As shown in an example variation illustrated in Fig. 7 A, the packet header 
compressor 25 is preferably situated at a node such as a packet data serving node 
(PDSN) 70. The PDSN node 70 is essentially equivalent to a Serving GPRS Support 
15 Node (SGSN) in the 3GPP architecture. The transceiver 29 is situated in a node of a 
radio access network (RAN) 72, such as a base station or radio base station node, for 
example. It should also be understood that packet header compressor 25 may instead 
be situated at a node of radio access network (RAN) 72. 



[00082] As another variation, shown in Fig. 7B, the multimedia server 21 can also be 
20 situated at a node such as the packet data serving node (PDSN) 70. In such case, the 
triggering node 60 can either be a separate and distinct node as shown in Fig. 7B, or 
alternatively the triggering node 60 can also be the PDSN node 70. 



[00083] In an example, non-limiting implementation, packet header compressor 25 may 
be configured in accordance with conventional, e.g., standardized compression logic 

25 such as ROHC. Advantageously, receipt and processing of the external trigger signal 
64 need not interfere with the internal compression logic of packet header compressor 
25, so that standardized compression logic can still be used without internal 
modification of the standardized compression logic. The external trigger signal 64 
interfaces with packet header compressor 25 in such a way as to obviate or render 

30 unnecessary certain aspects of the standardized compression logic, and/or facilitate 
certain advantageous input settings or parameters of the standardized compression 
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logic, but does so in such a way already accommodated by the standardized 
compression logic. 

[00084] In the above regard, a conventional header compressor is typically configured 
to start the lowest compression state upon receiving an initial packet of the media flow. 
5 Thus, the conventional header compressor does not receive an external trigger signal, 
but has its standardized compression logic launched based on content of the media 
flow. In addition, the conventional header compressor is configured to refresh at the 
lowest compression state upon expiration of a preset timeout, e.g., Timeout_l, as above 
discussed. 

10 [00085] Thus, in one example implementation, the packet header compressor 25 is 
capable of performing in the manner previously described with reference to the 
compressor of Fig. 1 and the ROHC profiles defined, e.g., in RFC 3095, RFC 3242, 
RFC 3408. And while being capable of launching its lowest compression state based 
on media content, rather than doing so such launch is bypassed and view of an earlier 

15 receipt of the external trigger signal 64. Moreover, as explained below, the preset 

timeout, e.g., Timeout, 1, can be set to a high value, or even infinity, and thus rendered 
essentially unnecessary. In other respects, the packet header compressor 25 and the 
state machine illustrated in Fig. 6 operates essentially in the manner previously 
described with reference to the compressor of Fig. 1 and the ROHC profiles defined, 

20 e.g., in RFC 3095, RFC 3242, RFC 3408. 

[00086] Fig. 8 illustrates basic, representative, example steps or events included in an 
example mode of a method for operating a communications network such as 
communications network 20 with its multicast/broadcast multimedia service. Fig. 8 is 
understood in conjunction with the example implementation of Fig. 7A, wherein a 
25 multicast/broadcast multimedia service is available over air interface 38 to remote unit 
40, with a media flow of the multicast/broadcast multimedia service being subject to 
unidirectional header compression logic by packet header compressor 25 at PDSN node 
70. In the Fig. 8 example, packet header compressor 25 is located at PDSN node 70 
and the header decompressor 46 resides at remote unit 40. 

30 [00087] Fig. 8 shows remote unit 40 sending an access request 62 in the form of a 

broadcast/multicast service request. As shown in Fig. 8, the sending of access request 
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62 is in two hops: a first request message or signal which is sent as step 8- la from 
remote unit 40 to PDSN node 70, and then a second message or signal which is sent or 
relayed as step 8-lb from PDSN node 70 to BCMCS controller 80. The BCMCS 
controller 80 can comprise, either partially or fully, the multicast/broadcast multimedia 
5 server 21. 

[00088] As an optional event, and prior to contacting BCMCS controller 80 on behalf 
of remote unit 40, PDSN node 70 can engage in an authentication/authorization step 8-2 
with an authorizing, authentication, and accounting agency node 82. 

[00089] Upon receipt of the access request 62, e.g., the request of step 8-lb, as step 8- 
10 3a the BCMCS controller 80 sends certain BCMCS channel acquisition parameters to 
PDSN node 70. As step 8-3-b the PDSN node 70 relays the BCMCS channel 
acquisition parameters to remote unit 40. 

[00090] Upon receipt of the BCMCS channel acquisition parameters, as step 8-4a the 
remote unit 40 responds to PDSN node 70 with a message to acknowledge receipt of 
15 the BCMCS channel acquisition parameters. As step 8-4b the remote unit 40 relays the 
BCMCS channel acquisition parameters acknowledge message to BCMCS controller 
80. 

[00091] In Fig. 8 it is presumed that the multicast/broadcast multimedia service 
proffered by BCMCS controller 80 has been on-going to other remote units in the RAN 
20 which have already been afforded access, and that such service continues to these pre- 
admitted remote units. Step 8-5a of Fig. 8 reflects the on-going broadcast/multicast of 
the multimedia service provided by BCMCS controller 80. The broken line 8-5b 
reflects the fact that the multimedia service is not yet being provided to the specific 
remote unit 40 which is requesting access via the access request 62 shown in Fig. 8. 

25 [00092] As a result of receipt of access request 62, and in addition to actions such as 
those depicted by step 8-3, as step 8-6 the triggering node 60 (e.g., BCMCS controller 
80 in the Fig. 7A example) generates and sends the trigger signal 64 to packet header 
compressor 25 situated at PDSN node 70. As mentioned before, the trigger signal 64 is 
external to the header compression logic comprising packet header compressor 25. The 

30 trigger signal 64, when applied to the packet header compressor 25, triggers a execution 
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of the lowest compression state of the header compression logic of packet header 
compressor 25. As such, as indicated by step 8-7, packet header compressor 25 sends 
initialization and refresh packets to header decompressor 46 of remote unit 40. Once 
initialization is accomplished, the BCMCS controller 80 can transmit the packets 
5 comprising the media flow to remote unit 40 as depicted by step 8-8. 

[00093] Transitions from state SO to state FO are permitted in the compression scheme 
in conventional fashion and do not require re-initiation of access. These are the 
transitions that are needed because of the nature of the packets to be compressed, for 
example, if there is a change in the behavior of some field that deviates form the 
10 patterns that were established and that allowed the compressor to operate in state SO. 

[00094] Packets for initializing the context are sent not only to the one mobile in 
question upon its access, but also the same packets are sent to all mobiles participating 
in the broadcast. The transceiver 29 (e.g., Base Station) sends only one channel, and 
the flow is sent only once over the entire cell area, and it does not matter how many 

15 remote units are listening as long as there is at least one, and everyone receives the 

same thing. So, in order to be capable of decompressing the stream, every remote unit 
must have the exact same context, otherwise the decompression will fail. If multiple 
registrations to the same BCMCS channel occur within the same short interval, it may 
be possible to aggregate these and only generate one single trigger instead of having 

20 one trigger for each access. This might help in areas with large number of mobiles 
where one channel may be especially in the demand (e.g., a sport event in a stadium 
where the replay of the last play is sent over BCMCS immediately after the play itself). 

[00095] Fig. 9 shows a second example embodiment communications network, 
particularly communications network 20'. The communications network 20' has the 

25 capability of generating the trigger signal 64 in response to the access request 62 in like 
manner as the embodiment of Fig. 5. As both a distinct and combinable aspect, and as 
further illustrated in Fig. 9, the triggering node 60 can also generate the trigger signal 
64 to trigger a transition to the lowest compression state of the header compression 
logic upon receipt of an indication of a decompression problem which has occurred at 

30 remote unit 40. In this regard, as shown in Fig. 9, header decompressor 46 comprises a 
decompression failure unit 90 which detects or ascertains the existence of a 
decompression problem which has occurred at remote unit 40. The decompression 
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problem can be, for example, a compression initialization failure or compression static 
context damage. 

[00096] Fig. 9 shows, as signal 92, the indication send from remote unit 40 to 
triggering node 60 regarding the decompression problem. The indication of signal 92 

5 is preferably in the form of an attempt by remote unit 40 to reinitiate access to the 
multicast/broadcast multimedia service provided by multicast/broadcast multimedia 
server 21. Thus, signal 92 is labeled in Fig. 9 as being a reinitiate access request. An 
example protocol and message which can be utilized as reinitiate access request 92 is 
the BCMCSFlowRegistration message for dynamic broadcast of the 3GPP2 Broadcast 

10 Control Protocol. Reinitiation essentially involves only restarting the procedure from 
scratch. 

[00097] Thus, remote unit 40 receives the multicast/broadcast multimedia service from 
communications network 20' over air interface 38, with a media flow of the 
multicast/broadcast multimedia service being subject to unidirectional header 

15 compression logic for compressing headers of the media flow. The remote unit 40 
comprises a transceiver 42 for receiving the media flow and a decompressor 46. The 
decompressor 46 is arranged so that, upon encountering a decompression problem with 
the media flow, the decompressor sends reinitiate access request 92 to reinitiate access 
to the multicast/broadcast multimedia service to the communications network (with an 

20 expectation that the request to reinitiate access will trigger a lowest compression state 
of the header compression logic). 

[00098] Fig. 10 shows basic, representative, example events/steps performed or states 
acquired by header decompressor 46 of remote unit 40 in conjunction with the example 
embodiment of Fig. 9. Event 10-1 of Fig. 10 shows header decompressor 46 
25 performing, or attempting to perform, decompression of a compressed packet header. 
Decompression continues as long as the decompression proceeds satisfactorily. In this 
regard, event 10-2 shows header decompressor 46 awaiting arrival of yet further 
packets whose headers are to be decompressed. Upon arrival, state/event 10-1 is again 
entered for performing the decompression. 

30 [00099] Should there be a decompression failure, e.g., a compression initialization 

failure or compression static context damage, state/event 10-2 is entered. At event 10-2 
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the header decompressor 46 discontinues its attempt of processing packets of the media 
flow, and proceeds to event 10-3. As event 10-3 the header decompressor 46 sends the 
reinitiate access request 92 to the triggering node 60 in order to request again access to 
the multicast/broadcast multimedia service. As previously explained, the reinitiate 
5 access request 92 can be a simple access request, i.e., the fact that the remote unit 40 
might have attempted this initiation before does not mean that a different message than 
the initial one would be sent. Thereafter, after header decompressor 46 of remote unit 
40 receives (as event 10-4) the static and dynamic context necessary for handling 
decompression of the compressed headers of the media flow, the header decompressor 
10 46 can eventually return to the event 10-1 of performing the decompression. Upon 
sending of reinitiate access request 92 as event 10-3, the header decompressor 46 does 
not necessarily have to discontinue the decompression attempts, because subsequent 
packets such as IR and or IR-DYN packets that may contain enough information to 
recover may arrive at any time. 

15 [000100] The method steps described above in conjunction with Fig. 8 are also 
applicable on the network side of the interface 38 for the example embodiment of Fig. 
9, the difference being in the Fig. 9 embodiment that the remote unit 40, upon detection 
of a decompression failure, sends the reinitiate access request 92. For example, in 
terms of the Fig. 9 embodiment the step 8- la and step 8- lb of Fig. 8 correspond to 

20 receipt and handling of reinitiate access request 92 rather than access request 62. In 
actuality, the reinitiate access request 92 is essentially a repeat of the access request 62 
previously sent by the remote unit 40, but prompted by a decompression failure rather 
than an attempt for an initial access to the multicast/broadcast multimedia service. Fig. 
8 also reflects the Fig. 9 embodiment in that (as step 8-6) the BCMCS controller 80 

25 generates, external to the header compression logic, the trigger signal 64 which is 
applied to the compressor to (again) trigger a lowest compression state of the header 
compression logic. 

[000101] It will be appreciated that the second embodiment of Fig. 9 is also 
susceptible to the variations of Fig. 7A and Fig. 7B, as well as other variations. 

30 [000102] Thus, the external trigger signal is generated either upon a remote unit seeking 
initial access to a multimedia service, and/or upon the remote unit (having suffered a 
decompression problem) seeking to reinitiate access to the multimedia service. The 
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external trigger signal thus obviates the conventional practice of having the compressor 
periodically (e.g., at the end of predetermined timeouts) returning (often needlessly) to 
the lowest compression state. The external trigger signal thus promotes spectral 
efficiency in the transmission of the broadcast and multicast services by reducing the 
5 overhead incurred from the periodic sending of larger packets involved in the lowest 
compression state, and tends to minimize delay. 

[000103] Thus, as described above, the access delay improvement is achieved by 
introducing/defining a system-specific (external to the header compression logic) IR 
state transition signal towards the compressor, e.g., trigger signal 64. This trigger 

10 signal 64 is generated by the system (e.g., communications network) upon an access or 
service registration attempt from a remote unit to the radio access network (RAN) when 
requesting access to a broadcast/multicast channel or service. The packet header 
compressor 25 receives this signal (trigger signal 64). The trigger signal 64 in turn 
triggers the context initialization and refresh (i.e. transition to IR State) procedure. A 

15 number of IR packets are thus sent upon reception of this trigger (optimistic approach), 
preferably over the BCMCS bearer to all receivers, or even using a separate bearer 
depending on how reliability is achieved. 

[000104] Inventors have thus recognized that the presence of the BCMCS 
controller/PDSN interface in the BCMCS architecture provides opportunities to 

20 optimize the header compression algorithm for broadcast/multicast services, by 

providing means for the BCMCS controller 80 to signal the PDSN node 70 that a new 
user is accessing the BCMCS service. In addition, the inventors have recognized that 
the presence of the BCMCS controller/remote unit interface in the BCMCS architecture 
provides opportunities to optimize the header compression algorithm for 

25 broadcast/multicast services, by providing means for remote unit 40 to make reliable 
access to the service. 

[000105] The reliability of the context initialization phase is achieved in two different 
ways. Reliability is first achieved by requiring that the decompressor 46 re-initiates the 
access to the broadcast/multicast IP service (in whole or in part) upon failure of the 
30 context initialization procedure at the decompressor (i.e., no IR packets initialize the 
new context). This makes it possible for the compressor to set the timeout value (U- 
mode) for the transition back to the IR state (Timeout_l) to a rather large (or even 
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infinite) value, based on: (a) the understanding that IR packets need only be sent upon 
a state transition trigger generated by the underlying system to the compressor upon the 
remote unit 40 making an access to the broadcast/multicast service; and (b) the 
agreement that the remote unit 40 will re-initiate the access upon static context damage 
5 or initialization failure. 

[000106] Reliability is secondarily achieved by requiring that packets initializing the 
context (at least the static part) be transmitted reliably, possibly on a separate bearer. 

[000107] The trigger signal 64 thus provides alternatives to the normal behaviour of 
having q remote unit 40 wait for the next periodic refreshes of the static part of the 
10 context over the multicast/broadcast channel to acquire the static context and transit to a 
higher compression state. 

[000108] The features herein provided allow the compressor to perform context 
initialization more efficiently, and removes the absolute need for periodic updates in 
multicast/broadcast services. For example, the value of Timeout_l can be set to infinite. 

15 This is made possible from the fact that other procedures (such as BCMCS information 
acquisition and/or registration to the service) can occur prior to the first packet within a 
session, and is particularly advantageous in multicast/broadcast systems where service 
and/or channel acquisition parameters are not statistically provided. The net result of 
this procedure is that fewer bits are transmitted and delay towards accessing the service 

20 is minimized. 

[000109] The generic terms "header compression", "header compressor" and "header 
decompressor" are used to show that the applicability of this idea is not limited to any 
specific header compression scheme. 

[0001 10] An open standard for a service called Instant-Talk-over-Cellular (PoC) is 
25 being developed for application in handsets for GSM, EDGE, UMTS and CDMA 
systems. Instant-Talk-over-Cellular (PoC) is a "walkie-talkie" in a cellular 
telecommunication system. PoC enabled handsets will most likely be equipped with a 
PoC-button (hardware or software). When this button is pressed the handset connects 
the user directly to a friend, a family member, or even a whole group of people of your 
30 choice, one-to-one or one-to many. Like a "walkie-talkie" the PoC service is half- 
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duplex, although full duplex may be available at a later stage. It is important to have 
low setup delay in order to allow for the user to start speak immediately after pressing 
the button. It is also important that the PoC service is supported in an efficient manner 
in the radio network since it is expected to be cheaper than circuit switched voice and 
5 since it is likely to become a mass-market service with high penetration. 

[0001 1 1] A typical usage of PoC is that a group of persons (e.g. youths, or professionals 
like workers at a building site) use the PoC terminals to keep the group updated on what 
is on-going. It is also likely that the group participants are geographically co-located. 
Current solutions use one dedicated radio channel (and core network) resource per 
10 group participant also in this scenario, which obviously is costly in terms of both radio 
and core network resources. It is thus foreseeable that such service may be used over a 
multicast (BCMCS) service. 

[0001 12] Thus, herein provided is, e.g., a method for reducing access time and 
improve compression efficiency in broadcast/multicast IP services with unidirectional 

15 header compression within a multicast/broadcast multimedia system. The system 
generates a state transition signal external to the header compression algorithm to 
trigger a compressor state transition. A trigger is derived using one or more 
broadcast/multicast channel acquisition events initiated by the remote unit. A 
downward transition is performed by the compressor for reducing the time required for 

20 the decompressor to reach static or full context. Preferably a transition to a lower 

compression state (e.g. IR state) occurs only upon reception of a state transition trigger 
from a system external to the header compression implementation (i.e. the conventional 
periodic downward transitions at the compressor are not performed). The header 
compressor and/or decompressor are/is implemented according to a header compression 

25 schemes in general. 

[0001 13] Advantageously, the access time for IP multicast/broadcast services is 
improved when using Robust Header Compression (ROHC) in the unidirectional mode 
(U-mode) of operation, i.e., it minimizes the delay required for the decompressor in the 
remote unit to reach the Full Context (FC) state when joining the channel. In addition, 
30 the spectral efficiency of broadcast and multicast IP services is maximized by reducing 
the overhead incurred from the periodic sending of larger IR packets. 
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[0001 14] Advantageously, the access time is improved by using an explicit state 
transition trigger from the system to the compressor when a remote unit accesses a 
broadcast or a multicast IP service. 

[0001 15] Thus, the embodiments described herein are particularly useful for one- 
5 to-many applications sent over multicast or broadcast radio channels (such as the so- 
called Push-to-talk VoIP application, or Push-to-talk over Cellular - PoC). The 
embodiments are also very relevant to the Broadcast Multicast Services (BCMCS) 
currently being defined in 3GPP2 by the BCMCS ad-hoc group. The embodiments are 
also potentially useful for 3GPP's Multicast/Broadcast Multimedia System (MBMS) 
10 work item and in GSM-Satellite, if ROHC operating in U-Mode is used. 

[0001 16] The embodiments are particularly applicable to most ROHC profiles, 
including (but not limited to) the ROHC LLA and the ROHC RTP header compression 
profiles. This is particularly applicable to most ROHC profiles, including - but not 
limited to - the ROHC-TCP (0x0006), ROHC RTP (0x0001), UDP (0x0002), IP 
15 (0x0004), ESP (0x0003), UDP-Lite (0x0008), RTP/UDP-Lite (0x0007) header 

compression profiles. Some of the proposed solutions also have the advantage of not 
requiring any change to any of the ROHC standards. 

[0001] It should also be understood that the header decompression techniques and other 
activities described herein need not be performed at nodes or terminals identically 
20 structured as those herein illustrated and/or described. Rather, various functions can be 
distributed or separated to other nodes or devices, or even networks (e.g., core network 
and radio access network). Moreover, even the header compression functions can be 
distributed over plural nodes and/or devices, if desired. 

[0002] In view, e.g., of the foregoing, the term "network node" as employed herein 
25 refers to any node or unit, or portion of node or unit, which performs, either in whole or 
in part, the context information transmission control described herein. 

[0001 17] Further, the node or device which hosts the header compressor 25 may or 
may not be located more than one node or network interface away from a receiving 
entity. For example, mention herein that context information is sent over an air or radio 
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interface to a receiving entity (e.g., remote unit 40) does not require that the header 
compressor 25 be situated in a node or location which borders the radio interface 

[0001 18] While the invention has been described in connection with what is 
presently considered to be the most practical and preferred embodiment, it is to be 
5 understood that the invention is not to be limited to the disclosed embodiment, but on 
the contrary, is intended to cover various modifications and equivalent arrangements 
included within the spirit and scope of the appended claims. 



